NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/misc-part1/1084

Internet Message Format | 1996-08-05 | 5.6 KB

Path: homer.louisville.edu!krsear01
From: [e-mail] (Kendall R. Sears)
Newsgroups: comp.sys.amiga.misc
Subject: Re: OS features
Date: 11 Jan 1996 20:51:58 GMT
Organization: University of Louisville, Louisville KY USA
Message-ID: <4d3t9e$[e-mail]>
References: <[e-mail]> <4b3h9s$[e-mail]> <hmAVx*[e-mail]> <[e-mail]>
NNTP-Posting-Host: homer.louisville.edu
X-Newsreader: TIN [version 1.2 PL2]

> There are other aspects of the philosophy of AmigaOS that can be preserved
> in a memory-protected rewrite of it.

> I also don't think it would be terribly hard to change a lot of software
> to work within a protected environment. I for one am quite careful to
> always set mn_Length - I hope other programmers are similarly careful.

> Devices and handlers can all run "under the line", and retain full
> access to the real address space (or a common virtual one). Message
> copying only has to happen to/from user-mode code. Ignore MEMF_PUBLIC.
> How hard is it to do changes like that? You don't have to change the
> structure of the program, and likely not any of its philosophy.

> Come on, lets discuss this, folks!

I usually just lurk but this one has prompted me to respond.  I have watched
discussions about the pros/cons of MP and AmigaOS both on usenet and bix for
what seems forever (at least since v1.1.)  One thing that always bothered me
about the discussions was that everyone covered the subject as a
"all-or-nothing" deal.  Arguments against ranged from "most software would die"
to "it (MP) would slow the system down."  Arguments for usually ranged from
"the user doesn't like the system crashing" to "it'd help developers find
errors."  This message is one of the few that covered the possibility of
partial protection.

Most who know anything about the internals of AmigaOS know that there are
several parts of the OS that assume that all memory is available.  Since most
crashes are not caused by the OS but by user programs a partial protection
should stop most crashes on machines with MMU's (68000's would still be
unprotected).

What I propose is a system to segregate the system memory into 3 parts:
  1) an area for the OS that is protected from writes by user processes
  2) an area for user code that is write protected
  and
  3) a "public" area where the data segments of programs are stored as well
     as message ports, and other data that need to be accessed by multiple
     programs.

These areas need not be contiguous, nor do they need to be allocated at system
start.  Use of the mem pools routines would provide a mechanism for
(de)allocation.  Each memory section would have a header that would tag that
area so that ownership could be determined.  Area 1 would be protected while
user programs are active and be made writable when the OS proper is active
(as would all system memory). Area(s) 2 would be write-protected while other
user programs are active and open when the owner process is active.  Area 3
would writable always.

Obviously, if a rogue program goes tromping through area 3 data could be
corrupted, but correctly written programs check packet validity upon receipt
to their port(s) and should be able to reject bad data, in the case where they
don't they could only trash themselves since everything else is protected.
Bad writes to volitile data in area 3 would be more dangerous.

One of the most used arguments against MP is that IPC relies on sharing of
memory.  Use of the above could provide a solution for this.  When
an OS legal program creates a message port, most of the time calls to OS
routines are used to create the port (via CreateMsgPort in v36 and above and
CreatePort from amiga.lib <v36.)  Changing those routines to use area 3 for
the ports would allow for message passing since user programs only get an
address to the port anyway.

Obviously, use of the MMU to change the status of memory sections will create
some slowdown, but since most, if not all, changes will occur with a context
switch this probably won't be noticed.

We could even take this a little farther... Assume that an Area 3 is set up
for each process, when a process disappears (for any reason) the OS could
call a DeletePool() on the area to recover most allocated memory (assuming,
of course, that AllocMem() et al. is changed to call the pool functions.)
The OS could either use an age mechanism or a task that occasionally runs
the pools looking for headers that contain ids that no longer exist.

Now, we have the case where we have an older program that, while not illegal,
isn't quite clean.  When the program tries to access a protected area that
it owns, a requestor would be presented to the user asking whether to allow
the access, suspend the program, or make all areas related to the process
"public".

This scheme wouldn't keep everything from crashing, nor would it be 100%
compatible, but I believe that it'd work and make the system much more
stable without significant speed penalties.

Kendall.
--
Kendall Sears               [e-mail]            ///
Programmer                                                           ///
Child Development Unit      What the Fool cannot understand he   \\\///
Department of Pediatrics    laughs at; thinking by laughter he    \XX/ Amiga
University of Louisville    shows superiority, instead of latent   Certified
                            idiocy.  - The Magic of Believing.     Developer
----------------------------------------------------------------------------
Life is a game you play once.  In order to win you must make a difference.
             Remember:  This is not a practice session.